What a design system owes you
A component library is a contract. Most of them are written badly, and the cost lands on the people using it.
A design system is usually described as a set of components. That framing is why so many of them are unpleasant to use. A design system is a contract, and components are only the part of the contract you can see.
The four promises
A system that is worth adopting makes four promises, and it should be possible to check each one in an afternoon.
- It will look right by default. If a component needs three overrides before it matches the designs, the default is wrong, not the person applying the overrides.
- It will not change under you without warning. A visual change that lands in a patch release is a broken promise, however small it looked in the diff.
- It will let you out. Every system meets a case it did not anticipate. The good ones provide a door; the bad ones provide a lecture.
- It will explain itself. Not documentation of every prop — an explanation of what the component is for, so people can tell when they are holding it wrong.
Escape hatches are a feature
Teams resist escape hatches because they are afraid of drift. That fear is reasonable and the conclusion is backwards. A system with no way out does not prevent divergence; it causes people to copy the component into their own folder and edit it there, where you will never see it again.
Give them a documented door and they will use the door. You will also learn something: the doors people take are a map of everything your system is missing.
Naming is most of the work
The name of a component determines how it gets used far more than its API does. Call it Card and it will end up wrapping everything on every page. Call it ArticlePreview and it will be used for article previews, and someone will come and ask you for the other thing they needed, which is the conversation you wanted.
Specific names are unfashionable because they feel less reusable. They are the reason a system stays coherent after the third team joins.
Who it is for
The honest test is not adoption percentage. It is whether a new engineer, on their second day, can build a correct screen without asking anyone. If they can, the contract holds. If they cannot, you have shipped a library and called it a system.